Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Just had an inkling of an idea, but could musl-libc be effectively used to build a standard B/LFS system and would there be any real problems in doing so?
Have been thinking of what all could be done with alternative software since we last experimented with runit and busybox (mdev and init) and this popped into my head.
Distribution: Void, Linux From Scratch, Slackware64
Posts: 3,151
Rep:
If youv'e got any details post them and I will give it a whirl, I have some spare partitions I use for mucking about with new builds, and as I have a complete lfs/blfs install sipted and package managed it's no problem to replace glibc with somthing else., just a matter of doing a search and replace for dependencies and making a build script for the new package.
Okay, after a day of work, I got as far as getting musl-libc installed. I'm going to work on libstdc++v3 soon, but so far the results have been encouraging.
I did however find that a lot of GCC will not build against musl without patches so right now the CLFS GCC musl patch for 4.7.3 has proved useful, but it is not without a problem or two. Musl requires a lot of effort to get GCC to build. In truth, it's a royal pain in the ass. An initial try at libstdc++v3 failed miserably. It refused outright to build at all.
I did however build musl-1.0.8 with the following build flags:
Code:
./configure --prefix=/tools \
--host=$LFS_TGT
but I may scrub the build and retry with a reworked ~/.bashrc file that targets musl builds specifically as in CLFS-embedded. Overall during the test phase the sanity check only had a warning:
Code:
dummy.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(){}
^
Code:
Elf file type is EXEC (Executable file)
Entry point 0x400310
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x0000000000000188 0x0000000000000188 R E 8
INTERP 0x00000000000001c8 0x00000000004001c8 0x00000000004001c8
0x0000000000000022 0x0000000000000022 R 1
[Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000534 0x0000000000000534 R E 200000
LOAD 0x0000000000000538 0x0000000000600538 0x0000000000600538
0x0000000000000180 0x0000000000000190 RW 200000
DYNAMIC 0x0000000000000560 0x0000000000600560 0x0000000000600560
0x0000000000000130 0x0000000000000130 RW 8
GNU_EH_FRAME 0x00000000000004b0 0x00000000004004b0 0x00000000004004b0
0x000000000000001c 0x000000000000001c R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .hash .dynsym .dynstr .rela.plt .init .plt .text .fini .eh_frame_hdr .eh_frame
03 .ctors .dtors .jcr .dynamic .got.plt .data .bss
04 .dynamic
05 .eh_frame_hdr
06
However, the sanity check did indeed pass.
To combat the GCC (libstdc++v3) issue, I may revert to GCC-4.7.3 for the build for sanity in code and patch unless anyone can provide a patch to get GCC working with musl to allow libstdc++v3 to build.
An alternative, though unwelcome, would be to try to build LFS with LLVM/Clang or another C compiler if one exists that is GNU/Linux and musl friendly, or should I just build the temp system with glibc?
I can see this being a problem further down the line, if gcc muscl needs an older version of gcc then there may (will) be a problem with new code needing newer versions of gcc. probably not practical.
Very true. Glibc must be used during the bootstrap at least, but GCC can be built with musl with the patches. I might revert to 4.7.3 for the test. It's stable GCC anyway, so unless anything doesn't play well, I can always try LLVM once I get that far in. Right now I'm only worried about getting a bootable system only.
I might grab Dragora's 4.9.2 GCC patch and try it though and the recipe. We'll see.
Okay, rebuilding 7.7 currently. Bootstrap will be built with glibc and the system will use musl-libc. Going to use the Dragora methods for installation. Hopefully no other patches will be needed.
Okay, rebuilding 7.7 currently. Bootstrap will be built with glibc and the system will use musl-libc. Going to use the Dragora methods for installation. Hopefully no other patches will be needed.
So you are building ch5 from the lfs book and then build a modified ch6 with musl using Dragora's recipes?
Yes. Currently the bootstrap seems to be able to build anything as needed due to the fact it builds GCC in a single shot rather than repeatedly. I think GCC's libstdc++v3 in standalone does require glibc due to the fact you're building it separate from GCC Pass 1 with a new libc compared to a different libc, and then rebuilding GCC yet again for Pass 2 against another libc rather than the native one. This might produce some incompatibilities and library conflicts because libstdc++v3 is built against GCC Pass 1 to the same standards and library code.
Now granted if GCC on the host was built against musl rather than glibc, the pass 1 GCC and libstdc++v3 would have the same libc and there would be no conflicts.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.